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1 nsrnioDUCTioN 

In the RAN WG2 meeting #32 was agreed that MBMS notification shall be send in such a manner 
that UE can received it in IDLE and in RRC connected mode, moreover, the notification should be 
such that UE is able to minimise the power consumption, i.e. UE is able to use DRX. 

Moreover, it was agreed that the reception of the notification is not guaranteed. However, the 
probability to receive MBMS notification should be high, meaning that some kind of repetition 
scheme is required for the case that some UEs receive first notification incorrectly. 

Moreover, the UE coming to the cell fi-om a cell inside MBMS service area or outside MBMS service 
are during the MBMS data transmission, should be able to discover possible MBMS transmission 
promptly in Idle mode or RRC connected mode. 

From the UTRAN complexity point of view, a notification solution, which could serve both idle and 
RRC connected mode is clearly beneficial. On the UE complexity and especially power saving point 
of view, a notification solution, which does not require continue reception or does not require DRX 
cycle other than current used for UE dedicated paging would clearly be advantageous. 



2 DISCUSSION 

2. 1 Pure PICK Based Notification 

The solution proposed in this section allows for continues provision of MBMS service notifications 
over the air interface, thus it inherently solves the repetition problem of MBMS notification. 
Moreover no new physical or transport channel is required minimizing downlink transmission power 
consumption and code utilization. 

The main idea is based on the use of the PICH channel and in particular of its 12 bits that are today 
reserved for future use. In the Figure 1, which illustrates one way to structure available bits, the 12 
bits are divided in three fields. 

Because the paging occasion is based on DRX cycle length and IMSI, the PICH frame, which UE 
shall listen to obtain paging indicator differs between UEs. Because the 6 bits is not enough to for 
complete notification solution, the first three bits defines a PICH fi-ame cycle, which the joined UE 
shall read to obtain complete MBMS notification information. Thus the joined UE in Idle mode or 
RRC connected mode (CELL_PCH or URA_PCH) shall calculate the paging occasion based DRX 



cycle length and its IMSI and listen not only one PICH frame but consecutive PICH as defined by first 
three bits to receive complete MBMS notification. 

To have only one notification solution also for CELL_DCH and CELL FACH, the UE, cable of 
receiving MBMS service simultaneously with other UE dedicated p-t-p services, should be able to 
listen also PICH based on its DRX cycle as CELL/URA_PCH state also in CELL_FACH and 
CELL_DCH state. 

The first 3 bits are also used as indicator/description of the value/parameter given in the second field, 
which indicates for e.g. the identification of a current and forthcoming MBMS service. The Figure 1 
also presents the other proposed identification/indications, which are required in MBMS notification. 
There is also proposed that the value 111 is used to have extension possibility of 6 bit 
indication/identification to 12 bits. 



The Figure 2 presents the BITMAP and the bit usage of the BITMAP'S 6 bits, is presented in Table 1, 
respectively. The third field is used to introduce 3 bit CRC for increasing the reliability of nine 
information bits, 
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000 


N©<t field defines the BITMAP 


001 


Next field Identifies to current MBMS sen/ice 


010 


Next field identifies the next MBMS service 


oil 


Next field identifies the SFN for Service announcenrBnt 


100 


Reserved 


101 


Reserved 


110 


Reserved 


111 


Previous frame was the first part of this franre 



Figure 1: PICH frame structure (pure PICH solution) 
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Figure 2: Bits in 6 bit BITMAP 
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Bit usage 



A 

A 


Counting ongoing for forthcoming MBMS service 
0 = NO, 1 = YES 


B 


Channel type selection of current MBMS service; 
0 = p-t-m, 1 = p-t-p 


C 


Transmission is Broadcast or multicast; 
0 = Broadcast, 1 = Multicast 


D 


Service announcement indicator 

0 = No service announcement 

1 = Yes service announcement 


EE 


p-t-m RB configuration set 

00, 01, 10, 11 bit combination according SIB 



Table 1: Bit usage in BITMAP 



The last two bits (EE) of the BITMAP are proposed to indicate the valid MBMS p-t-m channel 
configuration from set of possible configurations signalled on SIB, The principles how MBMS p-t-m 
RB parameters are transmitted to UEs are discussed in more detail in the contribution R2-030002 

2.2 Pros and Cons of the Proposed Pure PICH Approach 

Advantages: 

- No impacts to UEs supporting rel99/4/5 

- No new channel is needed to support continues MBMS notifications. 

- No new separate channel code allocation for notification channel is required 

- Downlink transmission power is only slightly increased 

- UEs, which are in RRC IDLE, CELL_PCH or URA_PCH, are in any case forced to wake 
up to listen PICH/SCCPCH in order to find out whether there is any paging message for 
them. 

- Only one DRX cycle is required in UE. 

- Only one notification method for UEs in IDLE and RRC connected, in case that MBMS 
capable UEs in CELL_DCH and CELL FACH shall also listen PICH 

- All UEs can find out what multicast services are currently available or will be transmitted 
in the near future. 

- UEs are able to start receiving MBMS transmission even is already ongoing, 

- No feedback is required from the UEs if not needed. 

- Paging concept is left as in Rel'PP 

Disadvantages: 

- Information bits on PICH are only protected by short CRC 

- UE must listen more than one consecutive PICH frame 

- UEs in CELL DCH or CELL FACH state must be able to listen PICH simultaneously 
with DPCH or SCCPCH respectively. 

2.3 Notification Using PICH Together with Notification Channel 

The solution proposed in this section is based on the use of the PICH channel and in particular of its 
12 bits that are today reserved for future use as in previous solution but also include separate MBMS 
control channel (MCCH). If the notification is the only control information to be sent, the name of this 
channel can be the Notification Channel (NCCH), not the MCCH. 

The main problem in usage of MCCH alone is the repetition interval so that each time, all joined UEs 
have to turn themselves to listen it. If the repetition interval is increased, UEs can stay longer period in 
DRX but the delay caused by notification to start MBMS service is also increased. From the UE point 
of view this introduces a new DRX cycle to be maintained together with Rel'99 paging. 



In this solution these problems are avoided by using the PICH channel for scheduling purposes for the 
NCCH. The proposed frame structure is presented in Figure 3. As in solution one and in Rel'99 the 
UE wakes up to listen the PICH based on its IMSI but UE does have to listen less consecutive PICH 
frames compared to solution one. By listening, in two consecutive PICH frames, the UE obtains 
information of currently transmitted MBMS service and scheduling/timing information of 
forthcoming MBMS notification on MCCH. 

Thus, the UE would have knowledge when to listen MCCH, enabling dynamic scheduling of 
notification without introducing new DRX cycles to UE. The dynamic scheduling of the notification is 
especially usefiil in case when no MBMS data is to be transmitted in near fiiture in cell, because the 
UE does not have to listen MCCH at all. 
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00 


N@d: field identifies to cunent MBMS service 


01 


field identifies scheduling InfomrBtion of the NCX>I 


10 


Reserved 


11 


Resen/ed 



Figure 3 PICH frame structure (PICH with NCCH solution) 



The principles how MBMS p-t-m RB parameters are transmitted to UEs are discussed in more detail 
in the contribution i?2-030002 



2.4 Pros and Cons of the Proposed Pure PICH Approach 

Advantages: 

- No impacts to UEs supporting rel99/4/5 

- Downlink transmission power is not increased 

- UEs, which are in RRC IDLE, CELL_PCH or URA_PCH, are in any case forced to wake 
up to listen PICH/SCCPCH in order to find out whether there is any paging message for 
them. 

- Only one DRX cycle is required in UE, 

- Only one notification method for UEs in IDLE and RRC connected, in case that MBMS 
capable UEs in CELL_DCH and CELL_FACH shall also listen PICH and MCCH 

- All UEs can find out what multicast services are currently available or will be transmitted 
in the near future. 

- Notification can be scheduled dynamically on MCCH 

- No feedback is required from the UEs if not needed. 

- Paging concept is left as in Rel'99 



Disadvantages: 

- New channel is needed to support continues MBMS notifications. 

- UE must listen more than one consecutive PICH frame 

- Downlinlc transmission powers are increased due to new channel 

- UEs in CELL_DCH or CELL_FACH state must be able to listen PICH and MCCH 
simultaneously with DPCH or SCCPCH respectively. 



3 CONCLUSSION 

It is proposed that the notifications solution using PICH without and with MCCH is studied further. 



